Method for the management of peripherals in an integrated circuit

ABSTRACT

A microprocessor-based integrated circuit for smart cards includes an application software layer and a peripheral management system including an intermediate software layer to manage the hardware processes on peripherals of the integrated circuit that are called up by at least one process of the application software layer.

FIELD OF THE INVENTION

The present invention relates to the field of electronic circuits, and,more particularly, to a system for the management of peripherals in amicroprocessor-based integrated circuit. Moreover, it relates especiallyto smart card type applications.

BACKGROUND OF THE INVENTION

One integrated circuit for a smart card type application is commonlycalled a microcircuit or an electronic micromodule. In addition to amicroprocessor, a microcircuit includes a number of other hardwareresources, generally called peripherals, such as counters, serialinterface circuits, random-number generators, clock-signal generators,etc. Also, memories are usually provided, particularly a read onlyprogram memory (ROM), electrically erasable programmable read onlymemories (EEPROMs) for storing application data, or working memoriessuch as random access memories (RAMs). It has also been the practice tohave a peripheral access controller that manages the address and databuses with the peripherals.

An integrated circuit of this kind is commonly delivered to a customerwho is not necessarily the final user. For this customer, at least oneapplication has been implemented in this integrated circuit, dependingon its final purpose. The present trend is towards the implementation ofseveral applications at a given time, one of which is activated by anexternal application.

These applications may be of different types. They may be, for example,a smart-card operating system, a cryptographic library that could beused for computations or signature verification, enciphering, orincorporated test software. This list of applications is not exhaustive.

These applications are implemented in the integrated circuit in the formof software processes in an application software layer. These processesare executed by the microprocessor of the integrated circuit. To performcertain operations of a given software process, the application softwarelayer must call up processes in the peripherals, hereinafter referred toas hardware processes (as opposed to software processes).

Usually, the application software does so directly, i.e., it directlymanages the peripherals of the integrated circuit. To this end, theintegrated circuit manufacturer provides all the necessary information,including the addresses of the different peripherals of the integratedcircuit, the addresses (in ROM program memory) of the tables of thehardware interrupt vectors, etc. These pieces of information arespecific to the integrated circuit. They enable the application softwarelayer to directly call up the hardware process on a peripheral. Theyalso enable the software layer to manage the peripherals in interruptmode. This means that it can continue to work for as long as theperipheral has not finished executing a requested hardware process(e.g., the programming of an EEPROM memory page).

In this case, it is the application software layer that directly managesthe hardware interrupts sent by the peripherals. This implies that itmust read and write registers and access the table of the hardwareinterrupt vectors in the ROM program memory to identify an interruptsource and undertake the necessary action.

Of course, further improvements in the security of the smart cards areconstantly being sought in an attempt to prevent any use of these cardsfor fraudulent purposes.

SUMMARY OF THE INVENTION

An object of the invention is to provide a secure system for managingperipherals in a smart-card integrated circuit.

This and other objects are provided according to the present inventionby an intermediate software layer acting as a safety barrier between theapplication software layer and the hardware resources of the integratedcircuit, namely the microprocessor and the peripherals. According to theinvention, this intermediate software layer manages all the peripheralson behalf of the application software layer. Thus, when a process of theapplication software layer calls up a hardware process on a peripheral,this call is managed by the intermediate software layer. For thispurpose, the invention uses a software interrupt instruction by which afunction of the intermediate software layer is called up.

When the intermediate software layer has terminated the processingoperation linked to the called-up function, it makes a return to theapplication software layer by a return from interrupt instruction.Through this mechanism, the application software layer no longer needsto know the hardware characteristics specific to the product, such asthe address of the table of the hardware interrupt vectors, the addressof the peripherals, etc. Thus, a safety barrier is created between thehardware resources of the integrated circuit and the application.

Furthermore, the execution time for a particular hardware process on aperipheral may be fairly lengthy (e.g., the programming of one or morewords in EEPROM memory). Preferably, to improve the performancecharacteristics of the card, the intermediate software layer mayimmediately release the application software layer that has called up ahardware process. In this case, the intermediate software layer itselfmanages the peripherals in the interrupt mode. This enables theapplication software layer to continue working and the intermediatesoftware layer to process other calls for hardware processes as needed.

In this case, when a peripheral has ended the execution of a hardwareprocess, it sends a hardware interrupt which stops the performance inprogress in the microprocessor and diverts it to the management of thehardware interrupts in the intermediate software layer. According to theinvention, the hardware interrupt processing in the intermediatesoftware layer may include interrupting the application software layerto enable this layer to end the corresponding process. Thus, there is asharing of the hardware interrupt processing, and the intermediatesoftware layer fulfils its function of a safety barrier by processingthe interrupt that corresponds to the hardware aspect. This isespecially the case for the reading and writing of registers to identifythe source of the hardware interrupt. Additionally, this is done whilethe application software layer carries out the rest of the processing ofthe interrupt which is related to the application.

Thus, the invention relates to a system for the management ofperipherals in an microprocessor-based integrated circuit for smartcards including an application software layer including at least oneprocess requiring the execution of hardware processes on at least oneperipheral of the integrated circuit. The system may include anintermediate software layer to manage the hardware processes called upby a process of the application software layer.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features and advantages of the invention are given in thefollowing description, by way of non-limitative example, with referenceto the appended drawings, in which:

FIG. 1 is a schematic diagram of a system for the management ofperipherals according to the invention;

FIG. 2 is a flow diagram illustrating an exemplary processing of a callfor a function of the application software layer by the intermediatesoftware layer according to the present invention; and

FIG. 3 is a schematic diagram illustrating an exemplary implementationof the invention using macro-instructions to make the calls between theapplication software layer and the intermediate software layer.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Turning now to FIG. 1, a system for the management of peripheralsaccording to the invention is now described. This system may generallybe applied to an integrated circuit CI including a microprocessor μP andperipherals P. It may be applied especially to integrated circuits forsmart-card type applications. The peripherals of such integratedcircuits usually include at least one ROM program memory includingsoftware processes of the application layer APPLI and the programcorresponding to the intermediate software layer LI according to theinvention.

The processes or programs of the application layers APPLI andintermediate layers LI are executed by the microprocessor μP. This iswhy it has been chosen to show them in FIG. 1 inside a logic boxrepresenting the microprocessor μP. At a given time, the microprocessorexecutes a given process or program of the application layer APPLI. Itmay in practice be interrupted in this execution by a hardware orsoftware interrupt.

According to the invention, when the processing of the application layerAPPLI performed by the microprocessor μP requires the execution of ahardware process in a peripheral, it uses the software interruptinstruction DIL to call up a function corresponding to the layer LI.This software interrupt start instruction DIL is executed by themicroprocessor μP. The processing of this software interrupt includesthe launching of the corresponding hardware process PM1 on the concernedperipheral P1. The result of this hardware process R (PM1) (which maysimply be an indicator to signify that the process is performed) isreturned to the application layer with the return from softwareinterrupt instruction RIL.

More specifically, and as shown in FIG. 2, the microprocessor μPexecutes (1) a process PL1 of the application software layer. In thisprocess PL1, microprocessor μP needs to execute a hardware process PM1.It then sends a software interrupt instruction DIL (2) to call up acorresponding function F (PM1) of the intermediate software layer. Thissoftware interrupt is processed by the intermediate software layer LI,which calls up (3) the corresponding hardware process PM1 on theconcerned peripheral P1, in interrupt mode. The intermediate softwarelayer LI hands over control (4) to the application software layer whichmay continue (5) with other processing operations. In particular, it maycall up other different operations of the intermediate software layer tolaunch other hardware processes.

When the hardware process PM1 is ended, the concerned peripheral P1sends (6) a hardware interrupt IT. This stops (7) the processing inprogress in the microprocessor μP, which in this example is a processingof the application software layer (although it could also be aprocessing of another function LI, for example) to send it on towardsthe management of the interrupt (8) by the software layer LI. Thismanagement includes the reading and writing of the table of hardwareinterrupt vectors enabling the identification of the source of thehardware interrupt, P1 in this example.

The management further includes the onward sending (9) of this interruptto the application software layer APPLI to enable the processing (10) ofthe interrupt by the caller software process. This onward sending isdone by a software interrupt instruction DIL sent this time by theintermediate software layer LI. When the concerned process PL1 of theapplication software layer has ended its processing of the interrupt, itreleases (11) the intermediate software layer LI which, in turn,releases (12) the peripheral P1. The microprocessor μP may then resume(13) the current processing at the place where it had been stopped.

The considerations related to the interrupt mode will not be presentedherein in detail. This is a typical mode of communication withperipherals that is well known to those skilled in the art. It cansimply be noted that the management system according to the invention,which uses the software interrupt start assembler instruction DIL, inpractice associates one domain with each of the processes PL1 of theapplications software layer and one domain with the intermediatesoftware layer LI. As such, there is one software interrupt vectorassociated with each of these domains. Thus, when a software interruptinstruction DIL is sent, the table of interrupt vectors is used toidentify the sender and launch the corresponding interrupt processingoperation. This table is in the intermediate software layer.

Furthermore, if a peripheral on which the intermediate software layer LIhas to launch a hardware process is busy, the step (4) of FIG. 2 inwhich the intermediate software layer LI releases the applicationsoftware layer includes the forwarding of a corresponding informationelement informing it that the peripheral is unavailable. The functionsof the intermediate software layer LI that may be called up may also bedefined for each domain. In such case, if the function of theintermediate software layer LI called up by a given process is not partof the definition of the field associated with this process, then theintermediate software layer LI will send an information element alongwith the return from interrupt instruction RIL indicating that thefunction is not accessible. If, to the contrary, the peripheral isavailable, it releases the application software layer by sending back toit a corresponding information element, informing it that its request isin progress in the concerned peripheral.

The invention therefore uses the possibilities offered by the softwareinterrupt mode of the microprocessor μP to create a safety barrierbetween the application software layer and the peripherals. Inparticular, the application software layer no longer needs to know theaddresses of the peripherals and of the tables of the hardware interruptvectors and other information, i.e., particularly important informationregarding security. It must only implement the software interrupt modethrough which it sends its calls for functions on the intermediatesoftware layer which manages the peripherals in its place.

In practice, in the case of the integrated circuits for smart card typeapplications, the source code (assembler) program compilers generally donot incorporate any software interrupt start assembler instruction DILand the associated return from interrupt assembler instruction RIL.Preferably, to prevent the developers of the processes of theapplication layer and the developers of the intermediate software layerLI from having to program in assembler language, the invention that theintermediate software layer LI may contain macro-instructions for eachfunction call.

The application software layer must therefore only call up amacro-instruction of the intermediate software layer LI. Thismacro-instruction includes the transfer of the parameters linked to thefunction LI to be executed and the execution of the assemblerinstruction DIL. Through this mechanism, it is the intermediate softwarelayer LI that sends the software interrupt instruction DIL. Theprocessing of this interrupt DIL by the intermediate software layer LIin turn sends a message toward a function LI. Thus, only the part of theintermediate software layer LI that contains the macro-instructions mustbe developed in assembler language. The application software layer andthe functions of the intermediate software layer LI are, for their part,developed in a very advanced language, typically C. A correspondingschematic block diagram is shown in FIG. 3.

The invention that has just been described creates a safety barrierbetween the application layer and the peripherals of the integratedcircuit. Furthermore, the sharing of the processing of the hardwareinterrupts between the intermediate and application software layersoptimizes communication between these two layers. This enables theconcerned application itself to process the hardware interrupt linked tothe application while at the same time allowing the intermediatesoftware layer LI to carry out its barrier role. This leaves to it allthe aspects of the processing related to the hardware, especially theidentification of the source of the interrupt.

1. A system for managing at least one peripheral of amicroprocessor-based integrated circuit for a smart card comprising: anapplication software layer comprising at least one process for callingup hardware processes to be executed on the at least one peripheral ofthe integrated circuit; and an intermediate software layer for creatinga safety barrier between said application layer and the at least oneperipheral by managing the hardware processes called up by the at leastone process of said application software layer; said applicationsoftware layer being mutually exclusive of said intermediate softwarelayer and calling up a function of said intermediate software layercorresponding to a hardware process to be executed, with the functionbeing called up by a macro-instruction of said intermediate softwarelayer, and with a programming language of the macro-instruction beingdifferent from a programming language of said application software layerand said intermediate software layer.
 2. The system according to claim 1wherein said application software layer calls up the function by sendinga software interrupt.
 3. The system according to claim 2 wherein saidintermediate software layer processes the software interrupt byverifying an availability of the called up function.
 4. The systemaccording to claim 2 wherein said intermediate layer manages thehardware processes in an interrupt mode.
 5. The system according toclaim 4 wherein said intermediate software layer processes a hardwareinterrupt of the at least one peripheral by using the software interruptof said application software layer to enable a processing operation insaid application software layer corresponding to the hardware interrupt.6. The system according to claim 5 wherein said intermediate softwarelayer releases the at least one peripheral after the processingoperation.
 7. The system according to claim 1 wherein themacro-instruction causes said intermediate software layer to send asoftware interrupt to call up the function.
 8. A smart card comprising:an integrated circuit comprising a microprocessor and at least oneperipheral; an application software layer comprising at least oneprocess for calling up hardware processes to be executed on the at leastone peripheral of the integrated circuit; and an intermediate softwarelayer for creating a safety barrier between said application layer andthe at least one peripheral by managing the hardware processes called upby the at least one process of said application software layer; saidapplication software layer being mutually exclusive of said intermediatesoftware layer and calling up a function of said intermediate softwarelayer corresponding to a hardware process to be executed, with thefunction being called up by a macro-instruction of said intermediatesoftware layer, and with a programming language of the macro-instructionbeing different from a programming language of said application softwarelayer and said intermediate software layer.
 9. The smart card accordingto claim 8 wherein said application software layer calls up the functionby sending a software interrupt.
 10. The smart card according to claim 9wherein said intermediate software layer processes the softwareinterrupt by verifying an availability of the called up function. 11.The smart card according to claim 8 wherein the macro-instruction causessaid intermediate software layer to send a software interrupt to call upthe function.
 12. An integrated circuit comprising: a microprocessor andat least one peripheral; an application software layer running on themicroprocessor comprising at least one process for calling up hardwareprocesses to be executed on said at least one peripheral integratedcircuit; and an intermediate software layer for creating a safetybarrier between said application layer and the at least one peripheralby managing the hardware processes called up by the at least one processof said application software layer; said application software layerbeing mutually exclusive of said intermediate software layer and callingup a function of said intermediate software layer corresponding to ahardware process to be executed, with the function being called up by amacro-instruction of said intermediate software layer, and with aprogramming language of the macro-instruction being different from aprogramming language of said application software layer and saidintermediate software layer.
 13. The integrated circuit according toclaim 12 wherein said application software layer calls up the functionby sending a software interrupt.
 14. The integrated circuit according toclaim 13 wherein said intermediate software layer processes the softwareinterrupt by verifying an availability of the called up function. 15.The integrated circuit according to claim 12 wherein themacro-instruction causes said intermediate software layer to send asoftware interrupt to call up the function.
 16. A method for managing atleast one peripheral of a microprocessor-based integrated circuit for asmart card comprising: calling up hardware processes to be executed onthe at least one peripheral of the integrated circuit using at least oneprocess of an application software layer; and creating a safety barrierbetween said application layer and the at least one peripheral bymanaging the hardware processes called up by the at least one process ofthe application software layer using an intermediate software layer; theapplication software layer being mutually exclusive of said intermediatesoftware layer and calling up a function of the intermediate softwarelayer corresponding to a hardware process to be executed, with thefunction being called up by a macro-instruction of the intermediatesoftware layer, and with a programming language of the macro-instructionbeing different from a programming language of the application softwarelayer and the intermediate software layer.
 17. The method according toclaim 16 wherein the application software layer calls up the function bysending a software interrupt.
 18. The method according to claim 17wherein the intermediate software layer processes the software interruptby verifying an availability of the called up function.
 19. The methodaccording to claim 16 wherein the macro-instruction causes theintermediate software layer to send a software interrupt to call up thefunction.